Skip to content

feat(grafana): MySQL 7362 and PostgreSQL 9628/14114 curated packs - #369

Open
shmsr wants to merge 2 commits into
mainfrom
feat/grafana-mysql-postgres-curated-packs
Open

feat(grafana): MySQL 7362 and PostgreSQL 9628/14114 curated packs#369
shmsr wants to merge 2 commits into
mainfrom
feat/grafana-mysql-postgres-curated-packs

Conversation

@shmsr

@shmsr shmsr commented Aug 20, 2026

Copy link
Copy Markdown
Member

Summary

  • Bundles curated packs for Grafana MySQL Overview 7362, PostgreSQL Database 9628, and PostgreSQL Exporter Quickstart 14114, so operators get exporter-specific typing, Helm/label ignore, and metric-name drift without a custom --rules-file.
  • Engine support those packs need: strip ignored_labels from native PromQL (and skip synthesizing those controls), do not yellow panels whose source metric is live_optional and absent, Grafana 5 singlestat units/decimals, and treat surviving EVAL aliases as Lens series.
  • Lab: mysql-load / postgres-load plus mysqld_exporter counter typing in the redis curated compose so 7362/9628 are not idle zero scrapes.

Test plan

  • pytest tests/test_curated_packs.py tests/test_migrate.py tests/targets/kibana/test_esql_utils.py
  • Migrate+upload 7362, 9628, and 14114 against prometheus_native metrics-* (--translation-mode auto --upload --smoke)
  • Confirm in a fresh Kibana view-mode tab (not a stale edit session) that leftover Helm Release controls are gone on 9628 and Instance options load on 14114 (pg_up, not up)
  • grafana-validate-uploaded on the three dashboards: no empty/error panels that are not documented pack approximations (9628 Version / Start Time remain approximate by design)

Operators migrating these community dashboards hit exporter typing, Helm
label noise, and metric-name drift that a generic PromQL pass cannot know.
Bundle packs plus the engine support they need so the installable CLI
produces usable Kibana panels without a custom rules file.
return None
if "computed_value" in metric_fields:
metric_col = "computed_value"
metric_fields = ["computed_value"]
return None
if "computed_value" in metric_fields:
metric_col = "computed_value"
metric_fields = ["computed_value"]
Bare instant gauges were kept native before the live-missing check, so
absent tiles scored green and Elasticsearch could emit value_$1/$2
instead of value. Fall through to telemetry-missing markdown, treat
CONCAT EVAL aliases as series keys, and expect ignored-label matchers
to stay native after stripping.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found three correctness blockers, so I cannot approve this yet.

  1. panels.py:2603 treats every metric absent from a resolver with discovery_status == "ok" as proven absent. merge_control_schema() also sets that status for intentionally partial control-schema hints. As a result, this PR drops native queries for metrics that simply are not listed in the partial fixture: test_k8s_cluster_affects_all_live_query_panels now emits 6 queries instead of 13 and fails on Python 3.11, 3.12, and 3.13 (reproduced locally). This matters beyond the test because operators using --control-schema can lose otherwise valid panels. Please distinguish exhaustive live field-caps from partial merged hints before applying the missing-metric gate, and keep/add regression coverage for the partial-control-schema path.

  2. The live_optional path can crash when all targets are optional and field-caps prove them absent. The loop records only tolerated_live_metric_target_refs, leaves translations and dropped_live_metric_targets empty, then indexes translations[0] at panels.py:4259. I reproduced this with a one-target optional_metric panel and received IndexError: list index out of range. Since this PR expands live_optional_metrics and claims graceful handling for absent optional telemetry, please add an explicit zero-translation fallback (for example, missing-telemetry markdown) plus an optional-only regression test.

  3. Two new registry pins are not the dashboards they claim to identify. Using this repository's scripts.fetch_community_corpus.canonical_sha256 against grafana.com gives:

    • 9628 revision 1: 2eda2afc28c140374b38d4bad2bc23b3e96667713a2187ad458117eb7ea131d4, not 521bac...; additionally the committed community corpus pins revision 8 (a3c1f753...) while this pack/manfiest says revision 1.
    • 14114 revision 1: 76b92bbeb9b2d8f3f8abec10b7cb016da87803deca34a99dddab9f668010a53d, not 5f9061... (the corpus already has the correct value).

Please correct the hashes and reconcile which 9628 revision was actually validated across registry.yaml, pack.yaml, the fidelity manifest, and the corpus. A test that validates registry pins against committed corpus entries would prevent this silent mismatch.

The focused PR suite passes locally (1048 passed, 36 subtests passed), but the full unit-test jobs are red because of item 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants